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1. REAL PARTY IN INTEREST 

The real party in interest is General Electric Company by way of the assignment 
recorded at reel 016212, frame 0534 from GE Medical Systems Global Technology 
Company, LLC, the Assignee of the above-referenced application by virtue of the 
Assignment to GE Medical Systems Global Technology Company, LLC, recorded on 
April 12, 2001, recorded at reel 011718, frame 0568. 

2. RELATED APPEALS AND INTERFERENCES 

Appellant is unaware of any other appeals or interferences related to this Appeal. 
The undersigned is Appellant's legal representative in this Appeal. GE Medical Systems 
Global Technology Company, LLC, the Assignee of the above-referenced application, as 
evidenced by the documents mentioned above, will be directly affected by the Board's 
decision in the pending appeal. 

3. STATUS OF THE CLAIMS 

Claims 1-21 are currently pending, and claims 1-21 are currently under final 
rejection and, thus, are the subject of this appeal. 

4. STATUS OF AMENDMENTS 

Appellant has not submitted any amendments subsequent to the Final Office 
Action mailed on October 11, 2006. 

5. SUMMARY OF CLAIMED SUBJECT MATTER 

Claim 1 sets forth a method for reporting status of work in progress that includes 
the step of periodically querying an electronic database 14 that contains data indicating 
an order number, a promise date, a request date, a shipment date, and a product category 
for a plurality of products/services offered (98, 102). Application, pg. 17, Ins. 16-20 . 
The method further provides comparing the promise dates and the request dates (114) and 
setting a proactive promise alert (116) if a promise date is later than a request date for a 
given order. Id., Ins. 20-23 . The method displays any proactive promise alerts with the 
order numbers for those given orders that have a promise date that is later than their 
respective request date. Id, pg. 18, In. 1 . 

A computer-readable medium is set forth in claim 9, the computer-readable 
medium having stored thereon one or more computer programs. Id., pg. 18, Ins. 4-5 . The 
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computer program(s), when executed by one or more computers, causes the one or more 
computers to populate a database (14) with data (36) to include an order number, a 
promise date, a request date, a shipment date, and a product category (20-28) for a 
plurality of orders. Id. Ins. 5-10 . The one or more computers are further instructed to 
periodically query the database (14) and compare promise dates to request dates (114). 
Id., Ins. 10-12 . The one or more computers are further instructed to set a proactive alert if 
the promise date is later than a request date (1 14a), and set a reactive alert if the shipment 
date exists and the request date is less than a user-defined number of days prior to a 
current date (122). Id. Ins. 12-17 . The computer then displays any promise and shipment 
alerts organized by product category and type of alert (126). Id., Ins. 17-18 . 

Claim 15 sets forth a computer data signal representing a sequence of instructions 
that, when executed by one of more processors, causes the one or more processors (16) to 
populate a database (14) with data (20-28) including an order date indicating a date an 
order is initially made, a request date indicating a date when a customer requests delivery 
of the order, a shipment date, when available, indicating a date when actual shipment will 
occur, and a product/service category for each order for a product/service (98, 102). Id., 
pg. 18, In 18 to pg. 19, In. 3 . The one or more processors (16) are further instructed to 
query the database (14) and compare promise dates to request dates for each order (114), 
and to check for the entry of a shipment date for each order (118). Id., pg. 19, Ins. 3-5 . 
The one or more processors (16) are then instructed to set a proactive alert (116) if any 
promise date is later than a request date (114a), and to set a reactive alert if a shipment 
date exists for an order and the request date is less than a user-defined number of days 
prior to a current date (120). Id., Ins. 5-8 . The one or more processors (16) are lastly 
instructed to display all proactive and reactive alerts by product/service category and type 
of alert (126). Id., Ins. 8-10 . 
6. GROUNDS OF REJECTION 

Claim 4 stands rejected under 35 U.S.C. §112, second paragraph. Claims 15-21 
stand rejected under 35 U.S.C. §101. Claims 1-21 stand rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Martin et al. (USP 5,809,479) in view of Dietrich et al. (USP 
6,032,121) and further in view of Schoenberg et al. (USP 6,322,502). 
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7. ARGUMENTS 
Rejection under 35 U.S.C. §112 
CLAIM 4 

The Examiner rejected claim 4 under 35 U.S.C. § 1 12, second paragraph, stating 
that "[i]n claim 4, the recitation 'displaying the proactive promise alerts with the order 
numbers by product category and type of alert' renders the claim indefinite." Office 
Action, October 11, 2006, p. 3. The Examiner further asserted that it was unclear 
whether the subject matter of claim 4 refers to different proactive promise alerts or a 
proactive promise and reactive shipment alert. Id. Applicant respectfully disagrees. 
That is, claim 4 depends from claim 1 and further defines one of the steps of the method 
of claim 1. Claim 1 calls for, in part a method for reporting status of work in progress 
including the step of displaying proactive promise alerts with the order numbers for those 
given orders that have a promise date that is later than their respective request date. 
Claim 4 further calls for, in part, displaying the proactive promise alerts with the order 
numbers by product category and type of alert. No reactive shipment alert is called for in 
claim 1 as the Examiner asserts, and thus, there is no confusion as to what claim 4 calls 
for. As such, claim 4 in not indefinite as the Examiner asserts and it is respectfully 
requested that the Board withdraw the rejection of claim 4 under 35 U.S.C. § 1 12, second 
paragraph. 

Rejection under 35 U.S.C. §101 
CLAIMS 15-21 

The Examiner rejected claims 15-21 under 35 U.S.C. §101 as being directed to 
non-statutory subject matter, stating that "[t]he system contains data structures (signals) 
not claimed as embodied in computer-readable media and therefore are descriptive 
material per se and are not statutory because they are not capable of causing function 
change is a computer." Office Action, supra at 3 . Appellant respectfully disagrees. As 
stated by the Examiner, claim 15 is directed to "data structures", and as such, calls for a 
manufacture or composition of matter that falls within one of the four enumerated 
categories of statutory subject matter. 
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Claim 15 calls for a computer data signal representing a sequence of instructions 
that, when executed by one or more processors, causes the one or more processors to 
execute a plurality of acts. As the computer data signal called for in claim 15 is a "data 
structure" that falls within one of the four enumerated categories of statutory subject 
matter as a manufacture or composition of matter, claim 15 constitutes patentable subject 
matter so long as it has a practical utility. See MPEP §2106(IV)(B) . In order to provide 
a prima facie case of unpatentability, the Examiner must thus show that claim 15 does 
not have a practical utility. Id. The Examiner has failed to do so here, but rather, has 
merely asserted that the computer data signal(s) "are descriptive material per se and are 
not statutory because they are not capable of causing function change is a computer." 
Office Action, supra at 3 . This is clearly not the case, as the computer data signal called 
for in claim 15 represents a sequence of instructions that, when executed by one or more 
processors, causes the one or more processors to execute a plurality of acts. That is, the 
computer data signal causes the one or more processors to, in part, populate a database, 
query the database, set a proactive alert, set a reactive alert, and display all proactive and 
reactive alerts. Thus, the computer data signal called for in claim 15 provides a practical 
utility in that it produces a "useful, concrete and tangible result." State Street Bank v. 
Signature Financial Group , 149 F.3d 1368, 1373-74 (Fed. Cir. 1998). 

In light of the foregoing, Applicant believes that claim 15, and the claims 
dependent therefrom, are directed to statutory subject matter. As such, Applicant 
respectfully requests the Board to withdraw the rejection under §101. 

Rejection under 35 U.S.C. §103(a) over Martin et al. (USP 5,809,479) in view of 
Dietrich et al. (USP 6,032,121) and Schoenberg et al. (USP 6,322,502) 
CLAIM 1 

As discussed in detail below, the Examiner has improperly rejected the pending 
claims. The Examiner has misapplied long-standing and binding legal precedents and 
principles in rejecting the claims under § 103(a) of Chapter 35 of the United States Code. 

Contrary to the Examiner's assertion, Appellant respectfully disagrees that the art 
of record supports a 35 U.S.C. § 103(a) rejection of the present claims. The burden of 
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establishing a prima facie case of obviousness falls on the Examiner. MPEP §2142 . 
Obviousness cannot be established by combining the teachings of the prior art to produce 
the claimed invention absent some teaching or suggestion supporting the combination. 
ACS Hospital Systems, Inc. v. Montefiore Hospital , 732 F.2d 1572, 1577, 221 U.S.P.Q. 
929, 933 (Fed. Cir. 1984). Accordingly, to establish a prima facie case, the Examiner 
must not only show that the combination includes each and every element of the claimed 
invention, but also provide "a convincing line of reasoning as to why the artisan would 
have found the claimed invention to have been obvious in light of the teachings of the 
references." Ex parte Clapp , 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985). That is, 
"[o]bviousness can only be established by combining or modifying the teachings of the 
prior art to produce the claimed invention where there is some teaching, suggestion, or 
motivation to do so found either explicitly or implicitly in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art." MPEP §2143.01 . 
"The fact that references can be combined or modified is not sufficient to establish prima 
facie obviousness." Id. (emphasis added). When prior art references require a selected 
combination to render obvious a subsequent invention, there must be some reason for the 
combination other than the hindsight gained from the invention itself, i.e., something in 
the prior art as a whole must suggest the desirability, and thus the obviousness, of making 
the combination. Uniroyal Inc. v. Rudkin-Wiley Corp ., 837 F.2d 1044, 5 U.S.P.Q.2d 
1434 (Fed. Cir. 1988). 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves or 
in the knowledge generally available to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations. MPEP §2143 . 

Appellant believes that a prima facie case of obviousness cannot be made based 
on the art of record because, as will be shown below, (I) the references are directed to 
very different purposes and therefore, there is no motivation to combine these references 
in a way done so by the Examiner, other than Appellant's own teaching; (II) the 
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combination would not have a reasonable expectation of success because the combination 
would not result in the same, or even a similar system as that presently claimed; and (III) 
all the elements of the present claims are not present in the references. The Examiner, as 
will be shown below, has failed to establish each of the three separate and distinct criteria 
necessary to support a § 103(a) rejection. 

The Examiner rejected claims 1 under 35 U.S.C. § 103(a) as being unpatentable 
over Martin et al. in view of Dietrich et al. and further in view of Schoenberg. The 
Examiner admitted that "Martin fails to disclose setting a proactive alert if a promise date 
is later than a request date for a given order and displaying the proactive alerts with the 
order numbers" and that "[i]f there is discrepancy between the promise date and request 
date, Martin merely recognizes the discrepancy and reschedules (see column 3, line 56 - 
column 4, line 23)." Office Action, supra at 4 . The Examiner thus applied Dietrich et al., 
stating that "Dietrich teaches the use of method of 'proactive' planning (as required by 
claim 1) in real-time (as required by claim 5) to provide advance warnings (see column 2, 
lines 58-61; see also column 6, lines 25 - column 7, line 14)." Id. 

The Examiner went on to state that "[t]he combination of Martin and Dietrich 
disclose all the limitations as set forth above but fail to explicitly disclose data related to 
product category of products or services, and setting a reactive alert if a shipment date 
exists and the request date is less than a user defined number of days prior to a current 
date." Id. at 5 . The Examiner thus applied Schoenberg et al. stating that "Schoenberg 
teaches the entry and monitoring of action items [and] the use of reactive alerts (see 
column 5, lines 39-48)" and that "it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to modify Martin/Dietrich with reactive alerts 
as taught by Schoenberg, because the use of reactive alerts are helpful management tools 
for correcting problems when undesired activities have already occurred." Id. 

(I) Lack of motivation to combine references 

Claim 1 calls for, in part, a method of reporting status of work in progress which 
includes the steps of comparing a promise date and a request date, setting a proactive 
promise alert if a promise date is later than a request date for a given order, and 
displaying the proactive promise alerts with the order numbers for those given orders that 
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have a promise date that is later than their respective request date. The art of record fails 
to teach or suggest such a process. In order to support a rejection under 35 U.S.C. 
§ 103(a), "there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art, to 
modify the reference or to combine reference teachings." MPEP §2142 . 

With respect to Martin et al., the Examiner admitted that "Martin fails to disclose 
a proactive promise alert" and that "Dietrich teaches the use of method of 'proactive' 
planning." Office Action, supra at 4 . The Examiner further stated that, "[i]t would have 
been obvious to one of ordinary skill in the art at the time the invention was made to 
modify Martin with the proactive warning (alert) taught by Dietrich, because an early 
warning system reduces the chance that undesired events will occur." Id. at 5 . Such a 
conclusion is only derived from Appellant's own application - it is Appellant's invention. 

The rescheduling of Martin et al. subjects the customer to accept a delivery date 
that is later than a requested delivery date. "The customer-expected delivery date is 
communicated to the customer, which then uses this date for purposes of on-time 
measurements." Martin et al., col. 4, Ins. 41-44 . That is, there is no alert but simply a 
rescheduling and a customer is expected to tolerate delivery irregularities and use such 
irregularities to gauge supplier performance. There is no need or motivation to generate 
or display any alert in the system of Martin et al. A scheduler, when scheduling a 
delivery after a customer expected date, already knows that a delivery will be late. 
Martin et al., col. 3, Ins. 61-66 . In short, there is no motivation to provide an alert for that 
which is already known. 

With respect to Dietrich et al., the Examiner stated that, "Dietrich teaches the use 
of a method of 'proactive' planning (as required by claim 1) in real-time (as required by 
claim 5) to provide advance warnings (see column 2, lines 58-61; see also column 6, lines 
25 - column 7, line 14)." Office Action, supra at 4 . Appellant does not necessarily 
disagree that Dietrich et al. teaches a method of proactive planning , however, (1) it does 
not teach proactive alerts and (2) there is no motivation in the art of record to combine 
the references in the manner done by the Examiner. 
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Dietrich et al. discloses a method of proactive planning , not proactive alerting. 
That is, the system of Dietrich et al. calls for generating a new plan if an event is not 
satisfiable by the current plan. Dietrich et al. states that "a proactive planning 
methodology can use information about changes in the input data used for planning to 
determine when a next plan should be produced." Dietrich, et al., col. 2, In. 66 to col. 3. 
In. 2 (emphasis added) . Dietrich et al. further states that "while the first method would 
typically be used to determine if a new plan should be generated immediately, this second 
method is used to determine the most appropriate time to begin the next planning process, 
that is, to schedule the next planning event." Dietrich et al., col. 8, Ins. 40-44 . That is, if 
there is a potential failure of the present plan, Dietrich et al. merely teaches scheduling a 
planning event either immediately or sometime in the near future. 

The systems of Dietrich et al. and Martin et al. are variants of one another. They 
each address delivery performance either through proactive plan generation as in Dietrich 
et al. or result orientated analysis such as the system of Martin et al. If operation in 
accordance with the system of proactive planning of Dietrich et al. were feasible, it would 
render the on-time performance system of Martin et al. useless. That is, by always 
having a newly generated plan schedule, Dietrich et al. schedules planning events to 
attempt to prevent missed shipments and Martin et al. monitors and tracks on-time 
delivery performance. Dietrich et al. suggests scheduling a new scheduling event when a 
plan cannot be satisfied, whereas Martin et al. teaches notifying users of late deliveries 
for gauging on-time delivery performance. The combination thus defeats the purpose of 
the reference. Additionally, this is not what is claimed in claim 1 nor does the art of 
record suggest or contain the motivation for combining the references in the manner done 
by the Examiner. 

Beyond the lack of motivation to combine Martin et al. and Dietrich et al., there 
also is no motivation to further combine Schoenberg et al. therewith. Schoenberg et al. 
discloses a medical information system that receives patient data and information from 
various sources and displays such information in a variety of formats for use by members 
of a medical team. See Schoenberg et al. Abstract . Schoenberg et al. discloses 
generating operational reminders for each action item that is transmitted between 
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different members of a patient's medical treatment team. See Schoenberg et al. col. 5, 
Ins. 40-42 . Schoenberg et al. further discloses that the system permits the entry of 
confirmatory information by respective members of a patient's medical treatment team 
and further, that if a treatment, i.e. medication, is not delivered as prescribed by the 
patient's doctor, an alarm is indicated to notify the medical team that an order, i.e. 
medicating of a patient, has not yet been carried out. See Schoenberg et al. col. 5, Ins. 43- 
48. 

The system of Schoenberg et al. provides for intercommunication between a 
plurality of individual healthcare personnel who may be associated with a specific 
patient. See Schoenberg et al. col. 6, Ins. 13-37. As a patient's primary physician 
determines a medication regiment for the patient, the patient's proscribed medication 
regiment is input into the system and communicated to the pharmacist who distributes the 
medications, and the resident assistants or nurses who administer the proscribed 
medications to the patient. Id. 

Unrelated to Schoenberg et al., Martin et al. discloses a system of tracking and 
reporting on-time delivery performance of goods. See Martin et al., Title . As stated in 
MPEP §2142, to support a rejection under 35 U.S.C. §103(a), "there must be some 
suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings." MPEP §2142 . The unrelated subject matter of these 
references is the first indication of the lacking of any motivation to combine the 
references. Additionally, and as argued above, Martin et al., fails to teach or suggest any 
alert and, in requiring the scheduling of a planning event when a plan cannot be satisfied, 
teaches away from any alert related to the non-satisfiable status of the plan. That is, a 
subsequent planning event will be scheduled regardless if all events on the schedule are 
satisfiable or multiple of the events are non-satisfiable. 

The Examiner maintained that "it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to modify Martin/Dietrich with reactive 
alerts as taught by Schoenberg, because the use of reactive alerts are helpful management 
tools for correcting problems when undesired activities have already occurred" and that 
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"in this case, Dietrich notifies a scheduler to reschedule." Office Action, supra at 5 . 
Again, the Examiner has not chosen a reference between Martin et al. and Dietrich et al. 
because neither shows what the Examiner contends. Appellant does not necessarily 
disagree that combining reactive and proactive alerts is beneficial to system operations; 
however, such disclosure is only in Appellant's filing and is not taught or suggested in 
the art of record. Additionally, such a conclusion requires that the system of Dietrich et 
al. not perform as it was intended. 

Dietrich et al. discloses scheduling a planning event if a task is unable of 
completion with the present schedule. Dietrich et al., Abstract . That is, there is no need 
or motivation to combine any alert disclosed by Schoenberg et al. with either of the 
systems of Martin et al. or Dietrich et al. as both the systems of Martin et al. and Dietrich 
et al. present functions which, only if they do not perform as intended, would require a 
reactive alert. The Examiner's interpretation requires the conclusion that one of ordinary 
skill in the art would appreciate that the systems of Martin et al. and Dietrich et al. will 
not perform as intended or disclosed and therefore would benefit from a reactive alert. 
As stated in MPEP §2143. 01. V, "if a proposed modification would render the prior art 
invention being modified unsatisfactory for its intended purpose, then there is no 
suggestion or motivation to make the proposed modification." MPEP §2143. 01.V . 
Accordingly, as the Examiner' s combination would require that the systems of Martin et 
al. and Dietrich et al. not perform as intended, there is no motivation to combine any alert 
which may be disclosed in Schoenberg et al. therewith. 

(II) Lack of reasonable expectation of success 

The second independent element required to support a 35 U.S.C. § 103(a) rejection 
is that there must be a reasonable expectation of success in combining the references to 
obtain the claimed invention. MPEP §2142 . There is no such reasonable expectation of 
success in the present case. Claim 1 calls for, in part, a method of reporting status of 
work in progress which includes the steps of comparing a promise date and a request 
date, setting a proactive promise alert if a promise date is later than a request date for a 
given order, and displaying the proactive promise alerts with the order numbers for those 
given orders that have a promise date that is later than their respective request date. That 



11 



Gupta et al. 



U.S. Serial No. 09/747,647 



is, the method of claim 1 defines a process wherein only those orders that have been 
proactively determined to be non-deliverable by their respective request dates have a 
proactive alert associated therewith. The combination of Dietrich et al. in view of Martin 
is incapable of providing such an alert. 

Even assuming that there is the requisite motivation to combine the teachings of 
the cited references, such a combination is incapable of operating in accordance with the 
method called for in claim 1. That is, Dietrich et al. teaches "us[ing] information about 
changes in the input data used for planning to determine when a next plan should be 
produced ." Dietrich, et al., col. 2, In. 66 to col. 3, In. 2 (emphasis added) . That is, a 
planning event is scheduled wherein the plan, i.e. all of the pending orders, is reviewed 
and updated. Martin et al. merely determines and records delivery status performance. 
The combination of the teachings of the references leaves a disjoint between reporting 
and displaying a planning event and the reporting of delivery performance. The 
combination of the two systems is incapable of reporting the status of work-in-progress 
because one system, Dietrich et al., is process focused and the other system, Martin et al., 
is customer performance focused. 

The addition of Schoenberg et al. does not correct the deficiencies of the 
combination of Martin et al. and Dietrich et al. or add to the expectation of success in 
achieving the current invention. Schoenberg et al. discloses a medical information 
system that receives patient data and information from various sources and displays such 
information in a variety of formats for use by members of a medical team. See 
Schoenberg et al., Abstract . Schoenberg et al. discloses generating operational reminders 
for each action item that is transmitted between different members of a patient's medical 
treatment team. See Schoenberg et al. col. 5, Ins. 40-42, (emphasis added) . A reminder 
generated from every action item can hardly be considered an "alert" when the "alert" 
indicates that an ordinary action has occurred. Schoenberg et al. further discloses that the 
system permits the entry of confirmatory information by respective members of a 
patient's medical treatment team and further, that if a treatment, i.e. medication, is not 
delivered as prescribed by the patient's doctor, an alarm is indicated to notify the medical 
team that an order, i.e. medicating of a patient, has not yet been carried out. See 
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Schoenberg et al., col. 5, Ins. 43-48 . Furthermore, the system of Schoenberg et al. does 
not include any request dates. Appellant is unaware of any medicinal distribution system 
wherein the patient — i.e. the customer of Schoenberg et al. — requests a time of 
medication. Because the doctor dictates when the patient will be medicated, "request 
dates" are wholly absent in this reference. See Schoenberg et al. col. 5, Ins. 38-48 . 

Assuming that the systems of Martin et al. and Dietrich et al. are combinable with 
the medical information of Schoenberg et al., the resulting combination does not include 
a reasonable likelihood of success of achieving the present invention. If an alert is 
generated for every order of Martin et al., as suggested by the preset mechanical 
reminders of Schoenberg et al., then after the scheduler of Martin et al. reviews the 
orders, and he moves an order so that the promise date is later than a request date. The 
system would then immediately generate an alert, according to Schoenberg et al., to alert 
the very scheduler who moved the data just seconds before. Since the scheduler already 
knows that the delivery date is after the customer-requested delivery date, the scheduler 
does not need an alert and, in fact, it would hinder his performance by requiring that he 
now must clear an alert of the condition he just created. See Martin et al. col. 3, In. 61 to 
col. 4, In. 1 . 

The combination of the disclosures of the references would provide a system 
where "alerts" are generated for ordinary action items. A person of ordinary skill in the 
art would readily appreciate that indications of normal operational conditions are not 
alerts. Furthermore, combining the reminder of Schoenberg et al. with the tracking 
system of Martin et al. and the planning system of Dietrich et al. results in a system 
where planning events are intermittently scheduled and non-satisfaction of a planning 
event is recorded and reported to a customer. Such a system is not what is presently 
claimed and such a system is incapable of achieving the benefits of the present system. 
As such, even combining the references in the manner suggested by the Examiner does 
not create a system that can report the status of work in progress on a particular 
product/order basis as called for in the present claims. The present invention improves 
upon the shortcomings of these cited references. 
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(III) Lack of references teaching, showing, or disclosing all the elements of 
the present claims 

Claim 1 calls for, in part, a method of reporting status of work in progress which 
includes the steps of comparing a promise date and a request date, setting a proactive 
promise alert if a promise date is later than a request date for a given order, and 
displaying the proactive promise alerts with the order numbers for those given orders that 
have a promise date that is later than their respective request date. The Examiner 
maintained that "Martin discloses a method of reporting status of work in progress ... 
[and] . . . fails to disclose setting a proactive promise alert if a promise date is later than a 
request date for a given order and displaying the proactive alerts with the order number." 
Office Action, supra at 4 . 

With respect to Martin et al., the Examiner stated that "[i]f there is a discrepancy 
between a promise date and request date, Martin merely recognizes the discrepancy and 
reschedules (see column 3, line 56 - column 4, line 23)." Id. This rescheduling subjects 
the customer to accept a delivery date that is later than a requested delivery date. As 
disclosed in Martin et al., "The customer-expected delivery date is communicated to the 
customer, which then uses this date for purposes of on-time measurements." Martin et 
al., col. 4, Ins. 41-44 . That is, there is no alert but a notification of a rescheduling, and a 
customer is simply expected to tolerate delivery irregularities and use such irregularities 
to gauge supplier performance. In the current application the proactive alert is intended 
for the manufacturer to affirmatively take corrective steps. This is indicated by the fact 
that the claim includes the step of displaying multiple proactive alerts, indicated by the 
plural form of alerts in claim 1 . Each of the alerts are displayed with the order number 
for those orders that have a promise date that is later than an associated request date 
thereby allowing corrective action. This is in stark contrast to the references cited by the 
Examiner. 

Martin et al. does not disclose the generation of any alert as called for in claim 1 
nor is there a need or motivation to generate or display any alert in the system of Martin 
et al. A scheduler, when he schedules a delivery after a customer expected date, already 
knows that a delivery will be late. Martin et al., col. 3, Ins. 61-66 . One of ordinary skill 
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in the art would appreciate that there is no alert, or motivation to provide an alert, for that 
which is already known. 

With respect to Dietrich et al., the Examiner stated that "Dietrich teaches the use 
of a method of 'proactive' planning (as required by claim 1) in real-time (as required by 
claim 5) to provide advance warnings (see column 2, lines 58-61; see also column 6, lines 
25 - column 7, line 14)." Office Action, supra at 4 . The system of Dietrich et al. calls for 
generating a new plan if an event is not satisfiable by the current plan and states that "a 
proactive planning methodology can use information about changes in the input data used 
for planning to determine when a next plan should be produced." Dietrich, et al., col. 2, 
In. 66 to col. 3, In. 2 . Dietrich et al. further states that "while the first method would 
typically be used to determine if a new plan should be generated immediately, this second 
method is used to determine the most appropriate time to begin the next planning process , 
that is, to schedule the next planning event ." Dietrich et al., col. 8, Ins. 40-44, (emphasis 
added) . Dietrich et al. discloses that if there is a potential failure of the present plan, a 
planning event is scheduled either immediately or sometime in the near future. 

Claim 1 does not call for scheduling or conducting a planning event as disclosed 
by Dietrich et al. Claim 1 calls for setting a proactive alert if a promise date is later than 
a request date for a specific order and displaying alerts with the order numbers for those 
orders that have a promise date that is later than their respective request date. That is, the 
method of claim 1 both identifies and displays those orders which cannot be delivered 
according to a present schedule. The system of Dietrich et al. indicates that a schedule 
needs to be generated and does not isolate and display those orders which have the 
potential of being delivered late as called for in claim 1 . 

With respect to the inclusion of Schoenberg et al. in the rejection of claim 1, the 
Examiner seems to rely on the reference for teaching "the entry and monitoring of action 
items, such as, orders for drugs or other treatments." Office Action, supra at 5 . While 
Appellant does not necessarily disagrees with this, the teachings of Schoenberg et al. in 
this regard do nothing to overcome the deficiencies of Martin et al. and Dietrich et al. 
That is, the further combination of Schoenberg et al. with the other cited references still 
results in a failure to teach or suggest all the elements called for in claim 1 . 
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For all the reasons set forth above, Appellant believes that the art of record fails to 
establish each requirement, as required under MPEP §2142, of substantiating a 35 U.S.C. 
§ 103(a) rejection of claim 1. As the art of record lacks the motivation to combine the 
references in the manner done by the Examiner, lacks a reasonable likelihood of success, 
and fails to teach or suggest each and every element of claim 1, Appellant believes claim 
1, and those claims that depend therefrom, are patentably distinct over the art of record. 
Appellant believes claims 2-8 are in condition for allowance at least pursuant to the chain 
of dependency. 

CLAIM 9 

Claim 9 calls for, in part, a computer-readable medium having stored thereon one 
or more computer programs that, when executed by one or more computers, causes the 
one or more computers to set a proactive alert if a promise date is later than a request 
date, set a reactive alert if the shipment date exists and the request date is less than a user- 
defined number of days prior to a current date, and display any promise and shipment 
alerts by product category and type of alert. The art of record does not disclose, teach, or 
suggest such a system. 

(I) Lack of motivation to combine references 

As set forth above with respect to claim 1, there is no motivation to combine the 
cited references in the manner done so by the Examiner. The systems of Dietrich et al. 
and Martin et al. are variants of one another. They each address delivery performance 
either through proactive plan generation as in Dietrich et al. or result orientated analysis 
such as the system of Martin et al. If operation in accordance with the system of 
proactive planning of Dietrich et al. were feasible, it would render the on-time 
performance system of Martin et al. useless. That is, by always having a newly generated 
plan schedule, Dietrich et al. schedules planning events to attempt to prevent missed 
shipments and Martin et al. monitors and tracks on-time delivery performance. Dietrich 
et al. suggests scheduling a new scheduling event when a plan cannot be satisfied, 
whereas Martin et al. teaches notifying users of late deliveries for gauging on-time 
delivery performance. The combination thus defeats the purpose of the references. 
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As relates to the combination of Schoenberg et al. with Martin et al. and Dietrich 
et al., the unrelated subject matter of these references is indication of the lacking of any 
motivation to combine the references. Furthermore, Dietrich et al. discloses scheduling a 
planning event if a task is unable of completion with the present schedule, and there is no 
need or motivation to combine any alert disclosed by Schoenberg et al. with either of the 
systems of Martin et al. or Dietrich et al., as both the systems of Martin et al. and Dietrich 
et al. present functions which, only if they do not perform as intended, would require a 
reactive alert. The Examiner's interpretation requires the conclusion that one of ordinary 
skill in the art would appreciate that the systems of Martin et al. and Dietrich et al. will 
not perform as intended or disclosed and therefore would benefit from a reactive alert. 
Accordingly, as the Examiner' s combination would require that the systems of Martin et 
al. and Dietrich et al. not perform as intended, there is no motivation to combine any alert 
which may be disclosed in Schoenberg et al. therewith. 

(II) Lack of reasonable expectation of success 

Claim 9 calls for, in part, one or more computer programs that periodically query 
a database and compare promise dates to request dates, set a proactive alert if the promise 
date is later than a request date, set a reactive alert if the shipment date exists and the 
request date is less than a user-defined number of days prior to a current date, and display 
any promise and shipment alerts by product category and type of alert. The Examiner's 
suggested combination lacks any reasonable expectation of success in providing the 
claimed invention from the disclosures of the references in the combination. As argued 
above with respect to claim 1, there is no reasonable likelihood of success from 
combining the teachings of Martin et al and Dietrich et al. in creating a work in progress 
monitoring system as defined in the present claims. The addition of Schoenberg et al. to 
the combination thereof does not increase the expectation of success. 

Martin et al. teaches a method of tracking and reporting on-time delivery status, 
or delivery performance. Martin et al., Abstract . Accordingly, a product must already be 
complete, i.e. no longer work in progress, if delivery status or delivery performance can 
be determined. Dietrich et al. discloses a system of maintaining a schedule based on 
changing process parameters. Dietrich et al., Abstract . That is, if a scheduled work in 
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progress is not going to be completed by a target date, a planning event is scheduled to 
update a processing schedule. Dietrich et al., col. 2, Ins. 6-18 . Martin et al. merely 
determines and records delivery status performance. The combination of the teachings of 
the references leaves a disjoint between reporting and displaying a planning event and the 
reporting of delivery performance. The combination of the two systems is incapable of 
reporting the status of work-in-progress because one system, Dietrich et al., is process 
focused and the other system, Martin et al., is customer performance focused. 

Schoenberg et al. discloses generating operational reminders for each action item 
that is transmitted between different members of a patient' s medical treatment team. See 
Schoenberg et al. col. 5, Ins. 40-42, (emphasis added) . A reminder generated from every 
action item can hardly be considered an "alert" when the "alert" indicates that an ordinary 
action has occurred. If an alert is generated for every order of Martin et al., as suggested 
by the preset mechanical reminders of Schoenberg et al., then after the scheduler of 
Martin et al. reviews the orders, and he moves an order so that the promise date is later 
than a request date, the system would then immediately generate an alert, according to 
Schoenberg et al., to alert the very scheduler who moved the data just seconds before. 

The combination of the disclosures of the cited references would provide a system 
where "alerts" are generated for ordinary action items. A person of ordinary skill in the 
art would readily appreciate that indications of normal operational conditions are not 
alerts. Furthermore, combining the reminder of Schoenberg et al. with the tracking 
system of Martin et al. and the planning system of Dietrich et al. results in a system 
where planning events are intermittently scheduled and non-satisfaction of a planning 
event is recorded and reported to a customer. Such a system is not what is presently 
claimed and such a system is incapable of achieving the benefits of the present system. 

(Ill) Lack of references teaching, showing, or disclosing all the elements of 
the present claims 

Claim 9 calls for, in part, setting a proactive alert if a promise date associated with 
an order is later than a request date associated with the order, setting a reactive alert if a 
shipment date exists for the order and the request date of the order is less than a user- 
defined number of days prior to a current date, and displaying any promise and shipment 
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alerts by product category and type of alert. The art of record fails to teach or suggest 
such a system. 

The rescheduling system of Martin et al. subjects the customer to accept a 
delivery date that is later than a requested delivery date. "The customer-expected 
delivery date is communicated to the customer, which then uses this date for purposes of 
on-time measurements." Martin et al., col. 4, Ins. 41-44 . That is, there is no alert but 
simply a rescheduling, and a customer is expected to tolerate delivery irregularities and 
use such irregularities to gauge supplier performance. A scheduler who schedules a 
delivery after a customer expected date, already knows that a delivery will be late. 
Martin et al., col. 3, Ins. 61-66 . In contrast, claim 9 calls for, in part, setting a proactive 
alert if a promise date is later than a request date. That is, if a product is promised by a 
date that is later than a customer request, the system corrects such events proactively such 
that the alert indicates that corrective action, if taken now, will prevent a delivery after a 
customer request. Such a system is simply not disclosed, taught, or suggested in the art 
of record. 

With respect to Dietrich et al., the Examiner stated that, "Martin and Dietrich 
disclose all the limitations as set forth above [with respect to claim 1] but fail to explicitly 
disclose setting a reactive alert if a shipment date exists and the request date is less than a 
user-defined number of days prior to a current date." Office Action, supra at 5 . The 
Examiner maintains that "Dietrich et al. teaches the use of a method of 'proactive' 
planning (as required by claim 1) in real-time (as required by claim 5) to provide advance 
warnings (see column 2, lines 58-61; see also column 6, lines 25 - column 7, line 14)." 
Id. at 4 . Appellant does not necessarily disagree that Dietrich et al. teaches a method of 
proactive planning , however, that is not what is called for in claim 9. 

Dietrich et al. does not provide a proactive alert associated with an order as called 
for in claim 9. Dietrich et al. discloses a system wherein, when an order cannot be 
produced by a desired date, a scheduling task can be scheduled to occur sometime before 
the desired date. See Dietrich, et al., col. 2, In. 66 to col. 3, In. 2. Claim 9 calls for 
setting and displaying proactive and reactive alerts specific to any order. Contrary 
thereto, Dietrich et al. teaches setting a scheduling date, wherein the entirety of the 
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schedule is reviewed and must be approved as compared to the order specific nature of 
the claimed invention. Id. Even combining the system of Schoenberg et al. with the 
systems of Dietrich et al. and Martin et al. does not achieve a system operable in 
accordance with claim 9. There is no proactive alert generated if a product promise date 
is later than a request date nor is there a display of any promise and shipments alerts by 
product category and type of alert. 

Schoenberg et al. discloses a medical information system that receives patient 
data and information from various sources and displays such information in a variety of 
formats for use by members of a medical team. See Schoenberg et al., Abstract . 
Schoenberg et al. discloses generating operational reminders for each action item that is 
transmitted between different members of a patient's medical treatment team. See 
Schoenberg et al. col. 5. Ins. 40-42 . Schoenberg et al. further discloses that the system 
permits the entry of confirmatory information by respective members of a patient's 
medical treatment team and further, that if a treatment, i.e. medication, is not delivered as 
prescribed by the patient's doctor, an alarm is indicated to notify the medical team that an 
order, i.e. medicating of a patient, has not yet been carried out. See Schoenberg et al., 
col. 5, Ins. 43-48 . That is, Schoenberg et al. discloses that an alarm or an alert is 
generated when an action item that was already scheduled to occur, has in fact not 
occurred - a reactive alert. 

Combining this alarm with the system of Martin et al. would result in a redundant 
system. That is, Martin et al. is directed to monitoring on-time delivery performance. 
Combining the alarm of Schoenberg et al. therewith would result in a system where, 
when a late delivery has occurred, even in light of generation of a new schedule as taught 
by Dietrich et al., an alarm is generated and indicates that a desired activity did not occur 
as scheduled. 

Claim 9 calls for a system wherein products are scheduled and associated by order 
number, a promise date, a request date, and a shipment date. A proactive alert is set and 
displayed if a promise date is later than a request date and a reactive alert is set and 
displayed if the shipment date exists and the request date is less than a user-defined 
number of days prior to a current date. There is no teaching or suggestion in the art of 
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record for a scheduling system which displays proactive alerts and reactive alerts as 
defined in claim 9. As stated by Schoenberg et al., the alarm disclosed therein is 
generated and displayed after a medication time has been missed. Additionally, as the 
proactive activity of Dietrich et al. is to generate a schedule plan, there is no proactive 
alert associated with any order as presently claimed. Accordingly, the art of record fails 
to teach or suggest a proactive alert as claimed or a reactive alert as claimed. 
Furthermore, as the art of record fails to teach or suggest the alerts as claimed, there is no 
disclosure in the art of record that teaches or suggests displaying a type of alert as called 
for in claim 9. 

For all the reasons set forth above, Appellant believes that the art of record fails to 
establish each requirement, as required under MPEP §2142, of substantiating a 35 U.S.C. 
§ 103(a) rejection of claim 9. As the art of record lacks the motivation to combine the 
references in the manner done by the Examiner, lacks a reasonable likelihood of success, 
and fails to teach or suggest each and every element of claim 9, Appellant believes claim 
9, and those claims that depend therefrom, are patentably distinct over the art of record. 
Appellant believes claims 10-14 are in condition for allowance at least pursuant to the 
chain of dependency. 

CLAIM 15 

The Examiner also rejected claim 15 under 35 U.S.C. § 103(a) as unpatentable 
over Martin et al. in view of Dietrich and further in view of Schoenberg et al. The 
Examiner stated that "it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to modify Martin/Dietrich with reactive alerts as taught by 
Schoenberg, because the use of reactive alerts are helpful management tools for 
correcting problems when undesired activities have already occurred." Office Action, 
supra at 5 . Appellant respectfully disagrees. 

(I) Lack of motivation to combine references 

Claim 15 calls for, in part, a sequence of instructions that cause a processor to 
query a database and compare promise dates to request dates for each order and check 
for the entry of a shipment date for each order, set a proactive alert if any promise date is 
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later than a request date, set a reactive alert if a shipment date exists for an order and the 
request date is less than a user-defined number of days prior to a current date, and display 
all proactive and reactive alerts by product/service category and type of alert. Claim 15 
calls for setting and displaying proactive alerts and reactive alerts based on a promise 
date, a request date, a shipment date, and a current date for an order. 

The Examiner's conclusion requires acceptance that one of ordinary skill in the 
art would believe that the system of Dietrich et al. will fail. Such an interpretation, that 
the system of Dietrich et al. is not adequate and does not generate a proactive plan, 
thereby requiring a reactive alert, renders Dietrich et al. unsuitable for its intended 
purpose. Further, no one would be doing this modification unless they had to present 
Application in front of them as a reference. That is, a person of ordinary skill in the art 
would not be motivated to combine a reactive alert with the proactive planning system of 
Dietrich et al. unless it was assumed that Dietrich et al. would be inoperable to 
proactively plan scheduling events to prevent incompleted action items. The Examiner's 
interpretation would require a person of ordinary skill in the art to disregard the novelty 
of Dietrich et al. and to assume that the proactive planning engine disclosed therein 
would actually fail for what it was intended to do. Appellant finds such an interpretation 
not only implausible, but unsupportable. 

Dietrich et al. discloses a system whereby a planning event is scheduled to 
generate a new plan at sometime in the future. Dietrich et al., Abstract . A person of 
ordinary skill in the art would appreciate that the proactive planning for schedule 
generation would render the need for any alert, let alone a reactive alert, redundant. That 
is, the plan is generated and scheduled because an action item is scheduled to not occur 
by a desired due date if operation proceeds according to the present plan. Clearly, the 
newly generated plan would schedule the action item which necessitated the generation 
of the new plan to satisfy the due date. Alternatively, if the action item cannot be 
satisfied with the present plan, there is no need to provide an alert related thereto as the 
action item is already known to be unable to be produced by a desired date. Accordingly, 
the art of record does not include the requisite suggestion or motivation to combine the 
references in the manner done by the Examiner. 



22 



Gupta et al. 



U.S. Serial No. 09/747,647 



(II) Lack of reasonable expectation of success 

Claim 15 calls for, in part, a sequence of instructions that cause one or more 
processors to set a proactive alert if any promise date is later than a request date, set a 
reactive alert if a shipment date exists for an order and the request date is less than a user- 
defined number of days prior to the current date, and displaying all proactive and reactive 
alerts by product/service category and type of alert. 

As previously argued with respect to claims 1 and 9, the combination of the 
Martin et al. with Dietrich et al. and further modified by Schoenberg et al. fails to provide 
an expectation of success from the combination thereof. The system of Martin et al. is a 
system wherein a human order scheduler is repeatedly queried to accept or deny delivery 
dates and regardless of that decision, delivery performance is monitored from a 
customer's satisfaction rating. The addition of the proactive planning system of Dietrich 
et al. allows automatic scheduling of a planning event but does not indicate the delivery 
or production status of any one order. The "reminders" of Schoenberg et al. are not 
generated by any date comparison. Schoenberg et al. merely discloses generating 
reminders for each action item. Schoenberg et al. col. 5, Ins. 41-42. As these reminders 
are generated after the entry of action items, any date associated therewith would be a 
delivery date. As such, there is no setting of a proactive alert if a promise date is later 
than a request date, along with the other limitations, as called for in claim 15. The 
combination suggested by the Examiner would merely require the order scheduler of 
Martin et al. to repeatedly clear reminders that do not indicate that a promise date is later 
than a request date but are merely mechanically created for each action item and do not 
indicate anything other than that an order has been placed. Such a system would clearly 
not achieve the benefits and success of the present invention. 

(III) Lack of references teaching, showing, or disclosing all the elements of 
the present claims 

Claim 15 calls for, in part, a sequence of instructions that cause a processor to set 
a proactive alert if any promise date is later than a request date, set a reactive alert if a 
shipment date exists for an order and the request date is less than a user-defined number 
of days prior to a current date, and display all proactive and reactive alerts by 
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product/service category and type of alert. As previously argued with respect to claim 9, 
Martin et al. and Dietrich et al., individually or in combination, fail to teach, suggest, or 
disclose any alert as defined by the present claims. Furthermore, Schoenberg et al. also 
fails to teach or suggest the type of alert called for in claim 15. 

Dietrich et al. discloses a system that schedules a planning event for generation of 
a production schedule based on changes to the production data. The proactive scheduling 
of the system Dietrich et al. does not associate a cause of an intermediate planning event 
with an order associated therewith. That is, whereas the system of Dietrich et al. is 
configured to "monitor the quality of a plan", the present invention is configured to 
automatically optimize the quality of the plan through association of product specific data 
as called for in claim 15. Dietrich et al. fails to teach to suggest the setting of a proactive 
alert if any promise date is later than a request date and displaying all proactive alerts by 
product/service category and type of alert. Dietrich et al. discloses scheduling a proactive 
planning event. In contrast, claim 15 defines the proactive alert as an alert that is specific 
to an order and for displaying the product specific proactive alert. There is no such alert 
disclosed in the art of record. Additionally, the system of Martin et al. discloses that a 
human order scheduler dictate a delivery date later than a request date. Martin et al. col. 
3, Ins. 61-66 . That is, there is no alert, or motivation to provide an alert, disclosed by 
Martin et al. when a person schedules the event that would necessitate the alert. Further, 
there is no displaying of all the proactive alerts as presently claimed. 

Furthermore, as argued above with respect to claim 9, the alarm of Schoenberg et 
al. only occurs after the point in time when the medication should have been, but was not, 
administered. There is nothing proactive about such an alert. Appellant does not 
disagree that Schoenberg et al. discloses generating reactive alerts for action items that 
are not completed by a delivery date. Schoenberg et al. col. 5, Ins. 45-48 . 

Claim 15 calls for setting a reactive alert if a shipment date exists for an order and 
the request date is less than a user-defined number of days prior to a current date. The 
alert of Schoenberg et al. is generated only after the action item has not been completed 
by the delivery date. Claim 15 defines the reactive alert as occurring, in part, when a 
request date is less than a user-defined number of days prior to a current date. That is, a 
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delivery has not yet been missed, but delivery cannot be made in accordance with the 
request date if the user-defined number of days is fixed. The alert of Schoenberg et al. 
indicates that a late delivery has already occurred. 

Claim 15 allows a user-defined number of days between the current date and the 
request date before an alert is generated. Such an alert is not taught or suggested by the 
dosing alarm disclosed by Schoenberg et al. As such, setting a reactive alert by a 
computer data signal if a shipment date exists for an order and the request date is less 
than a user-defined number of days prior to the current date, as called for in claim 15, is 
also not taught, shown, or even suggested in the art of record. 

Claim 15 further calls for the display of all proactive and reactive alerts by 
product/service category and type of alert. As previously argued with respect to claim 9, 
there is no support in the art of record for the display of the "type" of alerts. Schoenberg 
et al. only discloses one type of alert, and Martin et al. and Dietrich et al. do not disclose 
any alerts. Schoenberg et al. states that "[compliance with orders is tracked as well, and 
the display screen can indicate an alarm or other warning indicator which notifies the 
medical team that an order has not yet been carried out ." Schoenberg et al. col. 5, Ins. 45- 
48 (emphasis added) . That is, the alarm is provided when a medication that was 
supposed to be administered, has not been administered at the scheduled interval. The 
medication is already late. Granted, Schoenberg et al. does provide reminders before the 
action is required, but it only does so with a preset period of time. For example, if a 
doctor prescribes a certain patient be provided with a specific medication, a reminder is 
sent for each respective patient reminding the balance of the medical team that the 
prescription is expected to be administered. Schoenberg et al. col. 5, Ins. 41-42 . 

Claim 15, however, calls for a proactive alert if "a promise date" is later than "a 
request date" for a given order. Appellant is unaware of any medication that is promised 
in response to a patient's requested date of delivery . Claim 15 also calls for setting a 
reactive alert if a shipment date exists for an order and the request date is less than a user- 
defined number of days prior to a current date. There is no such alert taught or suggested 
in Schoenberg et al. That is, as commonly known; medication is to be delivered 
according to a doctor's predetermined administering procedure or date. The patient is 
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medicated according to the doctor's advice, not the patients' request, and an alert is 
generated if the medication has not been administered in accordance therewith. This alert 
is reactive to a late order and there is absolutely no comparison of a promised date to a 
request date as called for in claim 15. Schoenberg et al. discloses no request date 
whatsoever, for if it did, it would be a "request" by it's customer — the patient — and that 
makes no sense in the context of medical information system of Schoenberg et al. 

Accordingly, the step of setting a proactive promise alert if a promise date is later 
than a request dates for a given order, as called for in claim 15, is completely absent from 
the art or record. One reference, Martin et al., sets no alerts whatsoever; Dietrich et al. 
advances a scheduling event for an entire plan in response to an unacceptable delivery 
date; and Schoenberg et al. displays an alarm that is an indication that a desired activity 
has not taken place as scheduled. None of these disclosures, individually or in 
combination, achieves a system that operates according to the instructions called for in 
claim 15. That is, claim 15 calls for, in part, displaying a reactive alert is a shipment date 
exists for an order and a request date is less than a user-defined number of days prior to a 
current date. That is, the reactive alert called for in claim 15 occurs a user-defined 
number of days before a current date. Such a date dependant alert is neither disclosed nor 
suggested in the art of record. 

As such, the art of record fails to teach, suggest, or disclose displaying the type of 
alert since only one type of alert is generated by the combination of these references — a 
reactive alert. Minimally, three distinct elements of claim 15 are not taught, shown, or 
disclosed in the art of record. In addition thereto, as argued above, the references lack the 
motivation to combine the references in the manner done by the Examiner and lack a 
reasonable likelihood of success by any combination thereof. 

For all the reasons set forth above, Appellant believes that the art of record fails to 
establish each and every requirement, as required under MPEP §2142, of substantiating a 
35 U.S.C. § 103(a) rejection of claim 15. As the applied art lacks the motivation to 
combine the references in the manner done by the Examiner, lacks a reasonable 
likelihood of success, and fails to teach or suggest each and every element of claim 15, 
Appellant believes claim 15, and those claims that depend therefrom, are patentably 
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distinct over the art of record. Accordingly, Appellant requests favorable action over the 
rejection of claim 15 over Martin et al., in view of Dietrich et al. and further in view of 
Schoenberg et al. 
8. CONCLUSION 

In view of the above remarks, Appellant respectfully submits that the Examiner 
has provided no supportable position or evidence that claims 1-21 are obvious under 35 
U.S.C. § 103(a). Accordingly, Appellant respectfully requests that the Board find claims 
1-21 patentable over the prior art of record, direct withdrawal of all outstanding 
rejections, and direct the present application be passed to issuance. 



General Authorization for Extension of Time 

In accordance with 37 C.F.R. §1.136, Appellant hereby provides a general 
authorization to treat this and any future reply requiring an extension of time as 
incorporating a request therefore. As Appellant has previously paid for an appeal in the 
above-captioned matter, Appellant believes no fees are due for entry and consideration of 
this Appeal Brief. 

Respectfully submitted, Respectfully submitted, 

/Timothy J. Ziolkowski/ /Kevin R. Rosin/ 

Timothy J. Ziolkowski Kevin R. Rosin 

Registration No. 38,368 Registration No. 55,584 

Phone 262-268-8181 Phone 262-268-8100 

tjz@zpspatents.com krr@zpspatents.com 



Dated: March 12, 2007 

Attorney Docket No.: GEMS8081.055 

P.O. ADDRESS: 

Ziolkowski Patent Solutions Group, SC 
136 S. Wisconsin Street 
Port Washington, WI 53074 
262-268-8100 
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CLAIMS APPENDIX 

1. (Previously Presented) A method for reporting status of work in progress, 
comprising the steps of: 

periodically querying an electronic database that contains data indicating 
an order number, a promise date, a request date, a shipment date, and a product category 
for a plurality of products/services offered; 

comparing the promise dates and the request dates; 

setting a proactive promise alert if a promise date is later than a request 
date for a given order; and 

displaying the proactive promise alerts with the order numbers for those 
given orders that have a promise date that is later than their respective request date. 

2. (Original) The method of claim 1 further comprising the steps of: 
setting a reactive shipment alert if the shipment date exists and the request 

date is less than a user-defined number of days prior to a current date; and 

displaying any reactive shipment alerts with the order number together 
with the proactive promise alerts. 

3. (Original) The method of claim 2 wherein the user-defined number of 
days is equivalent to a number of days required for shipping a product to a customer. 

4. (Previously Presented) The method of claim 1 wherein the querying of the 
database is conducted automatically at regular time intervals, and wherein the step of 
displaying is further defined as displaying the proactive promise alerts with the order 
numbers by product category and type of alert. 

5. (Original) The method of claim 1 wherein the steps of the method are 
repeated automatically in real time. 
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6. (Original) The method of claim 1 further comprising repeating the steps 
of the method every time a request for information is made. 

7. (Original) The method of claim 2 wherein the proactive promise alert 
allows for correction of a potential late shipment and the reactive shipment alert provides 
data to prevent future late shipments. 

8. (Original) The method of claim 1 further comprising the steps of reacting 
to a proactive alert by performing one of: 

modifying the promise date to coincide with the request date; and 
notifying a customer that the request date cannot be fulfilled as desired. 

9. (Original) A computer-readable medium having stored thereon one or 
more computer programs that, when executed by one or more computers, causes the one 
or more computers to: 

populate a database with data to include an order number, a promise date, 
a request date, a shipment date, and a product category for a plurality of orders; 

periodically query the database and compare promise dates to request 

dates; 

set a proactive alert if the promise date is later than a request date; 
set a reactive alert if the shipment date exists and the request date is less 
than a user-defined number of days prior to a current date; and 

display any promise and shipment alerts by product category and type of 

alert. 

10. (Original) The computer-readable medium of claim 9 wherein the user- 
defined number of days is equivalent to a number of days required for shipping a product 
to a customer or providing a service to a customer. 
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1 1 . (Original) The computer-readable medium of claim 9 wherein the query 
of the database is conducted automatically at regular time intervals. 

12. (Original) The computer-readable medium of claim 9 wherein the one or 
more computer programs cause the one or more computers to repeat the actions of claim 
9 every time a request for information is made. 

13. (Original) The computer-readable medium of claim 11 wherein the 
regular time interval is between 0 and 60 seconds. 

14. (Original) The computer-readable medium of claim 11 wherein the 
regular time interval is greater than 1 minute. 

15. (Original) A computer data signal representing a sequence of instructions 
that, when executed by one or more processors, cause the one or more processors to: 

populate a database with an order date indicating a date an order is 
initially made, a request date indicating a date when a customer requests delivery of the 
order, a shipment date, when available, indicating a date when actual shipment will occur 
and a product/service category for each order for a product/service; 

query the database and compare promise dates to request dates for each 
order and check for the entry of a shipment date for each order; 

set a proactive alert if any promise date is later than a request date; 

set a reactive alert if a shipment date exists for an order and the request 
date is less than a user-defined number of days prior to a current date; and 

display all proactive and reactive alerts by product/service category and 

type of alert. 

16. (Original) The computer data signal of claim 15 wherein the user-defined 
number of days is equivalent to a number of days required for shipping a product/service 
to a customer. 
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17. (Original) The computer data signal of claim 15 wherein the query of the 
database is conducted automatically at regular time intervals. 

18. (Original) The computer data signal of claim 15 wherein the computer 
data signal causes the one or more processors to repeat the actions of claim 15 every time 
a request for information is made. 

19. (Original) The computer data signal of claim 17 wherein the regular time 
interval is between 0 and 60 seconds. 

20. (Original) The computer data signal of claim 17 wherein the regular time 
interval is greater than 1 minute. 

21. (Original) The computer data signal of claim 15 wherein the computer 
data signal causes the one or more processors to allow user modification of the promise 
date to coincide with the request date in response to the proactive alert if the 
product/service is available by the request date. 
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EVIDENCE APPENDIX 

— None — 
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